1. Field of the Invention
The technology relates to network test equipment simulating a network. Separately, the technology relates to the generation of network test packets and/or the generation of parts of network test packets.
2. Description of Related Art
The technology disclosed includes a hardware and software architecture for methods and apparatuses used to test routers, switches and the like, particularly high volume infrastructure devices.
Network test equipment tests component network equipment such as routers and edge devices, by simulating network traffic from and/or to an emulated network, thereby sparing the trouble of actually setting up a real network having the complexity of the emulated network.
In architectures primarily using FPGAs for test packet generation, the Frame Sequence Table is stored in high-speed memories attached to the FPGA. In addition, a frame control structures table, base content table, and modifier parameters table are stored in additional external memories accessible by the FPGA.
In architectures which involve the CPU generating a set of packet ingredients (dynamic and static), and transmitting those to the FPGA for completion of the packets, the order in which packets are produced is still controlled by a Frame Sequence Table in the CPU memory. All the additional tables required to produce the packet ingredients are also stored in CPU memory, so that no FPGA-accessible external memory is required. Various approaches are discussed by U.S. Pat. Nos. 7,869,381; 7,872,987; 7,872,988; and 7,933,220, all of which are incorporated by reference.
Flow control is addressed by Priority Flow Control implementation detailed in IEEE Std 802.1Q and IEEE Enhanced Transmission Selection (ETS) and Congestion Notification standards. The Priority Flow Control implementation detailed in IEEE Std 802.1Q arose from an effort to control the bandwidth of Ethernet frames. In the IEEE Std 802.1Q implementation, an overall Ethernet connection has up to 8 traffic classes. Each traffic class has a specified priority. Each packet being received and transmitted (or generated and transmitted, in the case of simulated test traffic) is marked with an associated priority or traffic class of that particular packet.
If a device downstream from the device receiving and transmitting traffic (whether actual traffic or simulated test traffic) is becoming congested for one or more traffic classes, the downstream device may send a Priority Flow Control message back to the upstream transmitting device. The Priority Flow Control message indicates that the upstream transmitting device must cease transmission on one or more of the traffic classes. The Priority Flow Control message also gives a required length of time for that cessation. When the required cessation time has elapsed for any given traffic class, the transmitting device may once again begin sending packets of that traffic class. Elementary flow control is provided by the Priority Flow Control message of IEEE Std 802.1Q, in the above manner.
A newer approach to priority flow control is taken by the emerging IEEE Enhanced Transmission Selection (ETS) and Congestion Notification standards. In ETS, there are up to 8 traffic classes, and each class is assigned a percentage of the total bandwidth. The assigned bandwidths have a resolution of 1%, and the total of the assigned bandwidths of all the traffic classes is 100%.
Each traffic class can respond to Priority Flow Control messages according to IEEE Std 802.1Q, by ceasing transmission for the specified length of time required by the message. However, with ETS, the remaining traffic classes that have not ceased transmission may increase their respective bandwidths to utilize any unused bandwidth resulting from Priority Flow Control which has caused a traffic class to cease transmission. Another cause for the unused bandwidth may be due to a particular traffic class that currently lacks enough packets to fill the respective allotted bandwidth of the particular traffic class. In order to utilize the available unused bandwidth, the allocated bandwidths for the ETS flows of the remaining traffic classes are proportionally increased.
Existing architectures for generating test traffic rely on a single Frame Sequence Table define the sequence of packets to be transmitted. Such architectures are not well suited to handling the requirements of the emerging IEEE Enhanced Transmission Selection (ETS) and Congestion Notification standards.
In constructing the Frame Sequence Table, the software and/or hardware architecture takes into account the relative bandwidths of all the various flows being simulated. The Frame Sequence Table is built accordingly, so that each flow appears in the table enough times to have the correct bandwidth. When the relative bandwidths change, then the underlying bandwidth assumptions no longer apply to the appearance frequency of each flow in the table of any existing Frame Sequence Table.
In response to the change in the relative bandwidths, the architecture at a minimum re-calculates and re-writes the Frame Sequence Table so that each flow appears in the table enough times according to the new bandwidth. With a large number of flows, and/or a large number of table entries, this is a sufficiently computation-intensive process, to take a significant amount of time. The requirements of the IEEE ETS specification strictly control the amount of time allowed to respond to a requested change in bandwidth, effectively preventing a single Frame Sequence Table under these circumstances from being compliant with the IEEE ETS specification.
Beyond the considerations imposed by a single Frame Sequence Table, various existing architectures for generating test traffic are not well suited to handling the requirements of the emerging IEEE Enhanced Transmission Selection (ETS) and Congestion Notification standards, because of memory bandwidth. Each packet to be queued and transmitted is written into the memory fabric, and later read out for transmission. So the switch fabric requires an instantaneous bandwidth of at least twice that of the Ethernet link serviced by the architecture.